The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. As the number of basic applications, and the media which it is possible to combine, increases, so will the number of services offered to the end users, giving rise to a new generation of personalised, rich multimedia communication services. The IMS is defined in the 3GPP Specification 23.228.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS 3 fits into the mobile network architecture in the case of a GPRS/PS access network. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer, or traffic plane and through which signals are directed to/from user terminals accessing the network. The GPRS network includes various GPRS Support Nodes (GSNs) 2a, 2b. A gateway GPRS support node (GGSN) 2a acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). A Serving GPRS Support Node (SGSN) 2b keeps track of the location of an individual Mobile Terminal and performs security functions and access control. Access to the IMS 3 by IMS subscribers is performed through an IP-Connectivity Access Network (IP-CAN). In FIG. 1 the IP-CAN is a GPRS network including entities linking the user equipment to the IMS 3 via the connectivity layer 1.
The IMS 3 includes a core network 3a, which operates over the Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 include Serving CSCFs (S-CSCF) and Proxy CSCFs (P-CSCF), which operate as SIP proxies within the IMS in the middle, Control Layer.
At the top is the Application Layer 6, which includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality. Application Servers 7 provide services to end-users on a session-by-session basis, and may be connected as an end-point to a single user, or “linked in” to a session between two or more users. Certain Application Servers 7 will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server 7).
IMS relies on Internet Protocol (IP) as a transport technology. Using IP for voice communications, however, presents some challenges, especially in the mobile community where Voice Over IP (VoIP) enabled packet switched (PS) bearers may not always be available. To allow operators to start offering IMS-based services while voice enabled PS-bearers are being built out, the industry has developed solutions that use existing Circuit Switched (CS) networks to access IMS services. These solutions are referred to as IMS Centralized Services (ICS). ICS is also the name of the Work Item in 3GPP Release 8 addressing these matters. ICS allows a User Equipment (UE) to connect to a CS access in order to have access to Multimedia Telephony services as defined in 3GPP TS 24.173. Referring to FIG. 2, a UE 8 can access an MSC Server 9 via a CS Access network 10. It also accesses a CSCF 5 via a Gm reference point, and a Service Centralization and Continuity Application Server (SCC AS) 11 via a Gm reference point.
SIP is used to perform service control between the ICS UE 8 and the SCC AS 11 over the Gm interface.
For a speech service, the ICS UE 8 can use its CS access to transfer voice media. The ICS specification defines how it is possible to use a CS bearer controlled via the Gm interface.
The 3GFPP Release 8 ICS specification describes two different types of MSCs; an unmodified MSC and an enhanced MSC. In an IMS architecture, the enhanced MSC can behave as a P-CSCF with some User Agent functions. It also provides inter-working between the CS signalling system in accordance with 3GPP TS 24.008 and SIP in accordance with 3GPP TS 24.229.
When a SCC AS 11 receives an incoming call, or other type of session request, with a voice component (or other type of media component that requires a codec, such as video), it will select an access domain. In this scenario, the SCC AS 11 decides to use the CS bearer. The SCC AS 11 includes in an INVITE request a telephone number (SCC AS PSI PN) and, in the SDP, a CS bearer indication. When the ICS UE 8 receives the INVITE request it will use the telephone number to set up the call in the CS domain by including the telephone number in the Set-up message. According to standard 3GPP TS 24008 procedure, the ICS UE 8 also includes the speech codecs that it normally uses for a speech call.
When the set-up comes to the MSC 9 it can either act as an enhanced MSC or a normal MSC. In the case that the MSC 9 acts as an enhanced MSC, it converts the set-up message into an INVITE request with the all the codecs included in the SDP, and includes the SCCAS:PSI as a Request URI. When the SCC AS 11 receives the SIP INVITE request it removes all codecs except one before it includes the SDP from the CS domain in the SDP answer sent to the originating UE. The SCC-AS 11 sends a SDP answer to the MSC server that will include the remaining codec chosen by the SCC AS 11. When the MSC server gets the SDP answer, which only includes the chosen codec, it can start radio bearer assignment.
In the case that the MSC acts as a normal MSC, it includes the codecs in the inter exchange signalling system, and the codecs will be transported to a Media Gateway Control Function (MGCF), where it is converted or included in SIP signalling that is sent to the SCC AS 11. The SCC AS 11 sends a SDP answer that is transported via the inter exchange signalling system. When the MSC server 9 receives the acknowledgement of the set up of the inter exchange circuits it can use the codec to set up the call.
Note that the ISDN User Part (ISUP) in the signalling system does not support the inclusion of codecs in the signalling. A normal 64 kbit/s PCM codec is assumed.
FIG. 3 shows the call signalling according to a known method, with the following numbering corresponding to the numbering in the Figure. An originating UE 12 sends an INVITE S1 to the SCC AS 11. The SCC AS 11 inserts an indication using SDP that a CS bearer will be used together with a telephone number named SCC-AS PSI PN and sends the INVITE S2 to ICS UE 8. The ICS UE 8 uses the telephone number to set up a CS call S4 to an MSC server 9. The setup request includes the SCC AS PSI PN number in the set-up message together with all speech codecs supported for the radio bearer. The MSC server 9, in accordance with TS 29.292, sends S5 a SIP INVITE request, which includes SCC AS PSI PN in the Request URI and the received codecs in the SDP, and indicates that a precondition is not met. In this scenario, the SIP precondition that must be fulfilled before the user is alerted is that the CS bearer must be established. This SIP INVITE request is sent S6 to the SCC AS 11. Before the SCC AS 11 sends an SDP answer to the originating UE 12 and the MSC 9, the SCC AS 11 includes in the SDP answer S7 to the originating UE 12 and the SDP answer S8 to the MSC server 9 only one codec of the received codecs from the MSC 9, which was also received from the originating UE. When the SDP answer S9 is received at the MSC 9 it initiates the radio assignment S10 and send a PRACK S11 to the SCC AS indicating that the precondition has now been is met. After acknowledging the PRACK, the SCC AS 11 sends a 200 (OK) S12 to the MSC Server 9, which then sends a connect S13 to the ICS UE 8.